Advanced Server Options: Monitored Repositories

In this tab of the Advanced Server Options dialog box, you can configure settings for tracing conditions, condition threads, and excluding users for each monitored repository.

The following are the maximum number of connections that can be made to the Laserfiche Server by default. (You can configure the actual number of connections in this tab and in the Task Threads tab.)

For each CPU, Workflow can make a maximum of:

• Four connections to the Laserfiche Server per workflow definition that has activities that connect to Laserfiche.
• Twelve connections to the Laserfiche Server from the tasks system.

Plus a total of:

• Five connections to the Laserfiche Server per monitored repository from the Subscriber threads.
• Four connections to the Laserfiche Server when you search for a user in a Laserfiche Trustee Directory from the Designer.

To configure monitored repository settings

1. Select the Advanced Server Options node or any server details in the center Details Pane of the Workflow Administration Console.
2. Click Properties in the Actions Pane, or right-click and select Properties.
3. Select the Monitored Repositories tab of the Advanced Server Options dialog box.



4. Next to Options for repository, use the drop-down menu to select the monitored repository you want to configure settings for. Use<Default> to configure the settings for all newly added or attached monitored repositories.
• Select Trace conditions to show how conditions are evaluated in the Subscriber Trace Log for the repository. Clear this option to hide this information.
• Specify how many starting rule, wait condition, and parent condition threads the selected repository can use when evaluating each of these types of conditions. Type a number next to each thread type, or use the scroll box (up-and-down arrows).

Note: Any thread changes will be updated with a delayed update mechanism to cause minimal disruption to the processing of events. The Subscriber updates options once a minute; therefore, any increase in the thread count will happen once a minute. If you decrease the number of threads, certain threads will be marked with a one minute lifetime. Each time one of these 'marked' threads processes an event, its lifetime increases by one minute. If the thread goes for one minute without being given an event, it will be reclaimed. If the thread count of any of the three categories is set to zero, the notification thread will immediately stop queuing new events. By excluding users, you can reduce the number of events the Subscriber processes.

• Under User Exclusion Filter, type in the name of any users (separated by semi-colons ";") that the subscriber should never process an event from. You can use * as a wildcard when specifying users.

Example: The Workflow User (as specified in a connection profile) is the username under which Workflow interacts with the Laserfiche Server and performs all actions that a workflow may call for. Many times you do not want changes the Workflow User makes to repositories to satisfy start rules or wait conditions. Learn more. Listing the Workflow User under User Exclusion Filter ensures that the Workflow Subscriber will ignore any events by the Workflow User.

• Select Cache activity notifications to store activity notifications from the Laserfiche Server. This option allows the Workflow Subscriber to make significantly fewer calls to the Laserfiche Server but uses more Workflow Subscriber memory. You may want to clear this option if you are having memory problems or if the Workflow Subscriber is backlogged more than ten minutes for processing events, starting rules, or wait conditions.
• The drop-down menu next to Parent Condition Optimization Level helps in situations where the Workflow Subscriber gets backlogged because it is inefficiently evaluating conditions on folders that undergo a lot of changes.
• None: Turns off the optimization system that helps the Subscriber evaluate parent conditions efficiently. Rarely, a system might experience timing problems that could be fixed by disabling the optimization system.
• Level 1: Workflow uses a short-circuiting mechanism to determine if a condition needs to be evaluated. Evaluation requests that were queued before a request that is already being processed will be ignored if the request being processed only has unsatisfied conditions.
• Level 2: Same as Level 1, except that the evaluation request will short-circuit regardless of whether the request being processed has satisfied conditions.